Move markdown lint disabling instruction below 2026.2 change log#19357
Conversation
|
I don't understand why this should be moved? everything under 2026.1 has invalid syntax we don't want to change to avoid translator work. We want to keep everything above that with the correct syntax. |
|
I had probably not thought to it so much, but it seemed strange to me that during 2026.2 dev cycle, we still lint 2026.1 change log. You may object that there won't be any change since 2026.1 is already linted. That's true as long as you don't change linter version. If you upgrade the linter, you may theoritically catch and fix new issues that would not have been caught with the previous linter version. Maybe we should just change this directive's position when we actually upgrade the linter? Feel free to close this PR if you feel it is not relevant. |
|
I think that we should keep linting until the translation freeze. So the disable instruction should stay where it is currently for now, but we should move it above 2026.1 for the last planned beta, or when branching for 2026.3 (the latter is probably easier) |
|
I think the easiest would just be to leave it though? I guess the only downside is if linting rules change we would need to move it up |
|
We could just add a new |
|
We'd be forced to do it when lint rules change, for example with #19311. When updating markdownlint we'd either have to lint the old changes, which we wouldn't do out of habit, or move the comment |
That relies on us remembering to do so when we update Markdownlint. It seems safer to me to add a step to the release process to add a comment to the changes file when each section is frozen |
|
It wouldn't be a matter of remembering, tests wouldn't pass. You'd be fixing the tests by moving the line |
Markdownlint fixes violations that it can fix safely. So when it's run as part of pre-commit.ci, it might modify sections that should be frozen |
|
Ah fair enough, I'm convinced to move it each release |
seanbudd
added
the
conceptApproved
seanbudd
left a comment
seanbudd
left a comment
There was a problem hiding this comment.
Thanks @CyrilleB79, I've opened a PR to fix up our template, and also consider moving it here to open source it
…ccess#19357) Fix-up of nvaccess#19354 Summary of the issue: In the PR to start 2026.2 dev cycle, the new 2026.2 section has been created, but the markdown disable instruction has remained below 2026.1 section. Description of user facing changes: None Description of developer facing changes: Moved the instruction to disable markdown linting below 2026.2 section.
…ccess#19357) Fix-up of nvaccess#19354 Summary of the issue: In the PR to start 2026.2 dev cycle, the new 2026.2 section has been created, but the markdown disable instruction has remained below 2026.1 section. Description of user facing changes: None Description of developer facing changes: Moved the instruction to disable markdown linting below 2026.2 section.
3 participants
Link to issue number:
Fix-up of #19354
Summary of the issue:
In the PR to start 2026.2 dev cycle, the new 2026.2 section has been created, but the markdown disable instruction has remained below 2026.1 section.
Description of user facing changes:
None
Description of developer facing changes:
Moved the instruction to disable markdown linting below 2026.2 section.
Description of development approach:
N/A
Testing strategy:
Not tested. A careful review should be enough.
Known issues with pull request:
None
Additional remark
It seems that internally at NV Access, you have a task list that you copy / paste in the initial description of each PR starting a new dev cycle. It would be the opportunity to update also this task list to mention that the linter command should be moved below the newly created section.
Code Review Checklist: